A tablespace transport mechanism is a powerful and very useful mechanism for importing/exporting data between databases. A tablespace is a collection of storage containers (e.g. files) used to store data for database objects (e.g. relational tables). A tablespace transport mechanism exports tablespaces from a “source database” and imports them into a “destination database”. This capability allows the files of a tablespace to be copied using operating system utilities for copying files, which run much faster than other techniques for bulk transfer of data between databases. Such other techniques involve executing queries and insert statements.
A tablespace is imported to a database by attaching it to the database. The term “attach” refers to configuring a database and/or its database server so that the tablespace can be used by the database server to store, access, and/or modify database data in the tablespace.
A tablespace may be transported to a database by creating a separate copy of the tablespace from the original source database and attaching it to the destination database. While the copy is being made, operations on the tablespace are restricted to read-only operations.
Restricting a source tablespace to read-only operations for any period of time can be disruptive to users of the database. Separate copies of the tablespace can be generated using other techniques that do not require that the source tablespace be rendered read-only, but such other techniques are expensive in terms of manual effort and/or resource usage.
For example, backup utilities may be used to automatically produce an entire database that contains the source tablespace. This procedure automatically creates separate copies of all the source tablespaces in a separate database of another database server from backups of the source database. Thus, the source tablespaces are not used and remain fully accessible while the duplicates are being produced.
However, use of this capability has several major drawbacks. First, a separate database server requires manual effort to install and/or provision resources for. Second, the database can be huge; duplicating one can require a lot of storage resources, time, and processing.
Other approaches avoid the need to duplicate the entire database, but the approaches are manually intensive and error prone. For example, a human DBA configures from scratch and starts a separate database server with a new database. Next, from backup, the DBA restores and recovers in the new database only the tablespaces to export as well as other system required tablespaces. This creates separate copies of tablespaces to export. This procedure involves many steps that must be manually performed by the DBA.
Clearly, there is a need for an approach for exporting tablespaces that does not require rendering source tablespaces read-only and that requires less resources or manual effort to perform.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.